突撃！隣のDevOps 【エウレカ編】

突撃！隣のDevOps

#体験レポート

#事例

#DevOps

aratafuji

2018.09.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、DevOps導入支援担当の藤村です。突撃！隣のDevOpsが帰ってきました！パート1からなんと2年ぶりのパート2、2といえばペア、ペアといえばPairs！ということで、今回はPairsを運営するエウレカさんにお邪魔して、DevOpsに関して根掘り葉掘り聞いてきました！

突撃！隣のDevOpsとは

パート1からあまりに時間が経っているため、改めてこのシリーズの趣旨について再掲します。

突撃！隣の開発環境では各会社さんの開発の方法や、どのような体制で開発をしているのかという形で、「開発」に焦点を当てたインタビューをさせていただいていました。実際、ソフトウェアサービスと言うのはリリースしてからがスタートであり、日々の改善活動や安定運用を行うため、開発（Development）と運用（Operations）が協力し合いながらビジネス要求に対し、早くかつ柔軟に対応していくかが求められます。そこで、突撃！隣のDevOpsでは、各会社さん毎にどうやってDevOpsを文化、プラクティス、ツールと言う観点でどのように実現しているかについてインタビューを行っていきます。

エウレカ紹介

どのようなサービスをやっている

「かけがえのない人との出会いを生み出し、日本、アジアにデーティングサービス文化を定着させる。」をビジョンに、「すべての人が、人生の可能性を拓いていける世界をつくる。」をミッションに掲げ、私たちのサービスで、誰かの人生をよりよいものにすることを目指して、恋愛・婚活マッチングサービスの「Pairs」と、カップル向けコミュニケーションアプリ「Couples」の運営をしています。

インタビューに答えていただいた方

今回のインタビューは、SREチームの方にお答えいただきました。

恩田拓也さん
- SREチーム責任者
- DevOps Days Tokyo2018登壇者
坂田純さん
- SREチームシニアエンジニア
- DevOps Days Tokyo2018登壇者
山本真嗣さん
- SREチームシニアエンジニア

SREチームとは

SREチームは、「会社の目指すビジネスの実現の阻害確立を上げる要因を全て排除する事」をチームのミッションに掲げ、以下の6つの戦略の推進を担っているチームだそうです。

99.95%の可用性を目標に、事業的な機会損失を最小化する
ブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する
運用自動化および自己修復可能なシステム基盤構築による少数精鋭での運用体制を確立する
定期的なキャパシティプランニングに基づくコストコントロールを行うことで利益率の向上へ寄与する
顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をはかる
事業価値最大化の為の施策サポートを行う

運用体制については、ビジネス規模の拡大とともに運用負荷も比例して拡大しては意味がないので、ビジネス規模が拡大しても今の運用工数が比例しないシステム基盤作りを特に意識しているとのことでした。また、単にシステムの安定稼働のみに注力するのではなく、マイクロサービスやデータ分析基盤の構築、またAIチームと共同で目的外ユーザー(Pairs上でセミナーの勧誘など、本来の目的ではない使い方をするユーザー)検知システムの構築などもSREチームが担当しているそうです。

SREチームは全員で6名。クラウドネイティブ世代のインフラエンジニアから、ネイティブアプリ開発からキャリアをスタートしたエンジニア、さらにインターン経由で入社した新卒エンジニアなど、メンバーの経歴はバラバラですが、皆が開発経験者ということでDev側の視点やニーズを理解できていることが強みだと話されていました。

後述するダッシュボードを見ながらスタンディングミーティングするSREチームの皆さん。

顔が見えないのでこっち向いて下さーい。

左から山本さん、恩田さん、原田さん、坂田さんです。

DevOpsについて

文化

御社の考えるDevOpsの定義とは？

定義
- プロダクトの改善、改修によるKPI達成を目標とする開発チームと、可用性やサイトパフォーマンスの最大化を目標とする運用チームにおける局所的な利益相反をこえて会社にとって全体最適な行動を取るための行動様式および概念、それを実現するためのエンジニアリング全般

上記のような定義を掲げてもらいましたが、恩田さんが入社された2015年4月の段階では、エウレカにはOps的なインフラチームは存在しておらず、CTOと新卒メンバーが開発しながらインフラも見ているような状況だったそうです。その後事業が伸びるに従ってパフォーマンスなどの問題が出始めたので、インフラチーム(現SREチーム)が発足したとのことで、特にエウレカにおいては開発チームと運用チームの間で衝突が起きていたわけではないとのことでした。

問題が起きたから作ったというよりも、問題が起こる前に組織体制化したとのことで、先手先手を打っている印象を受けますね！

なぜDevOpsに取り組んでいるのか？

取り組んでいる理由
- 開発者の生産性を最大化(ユーザ価値提供速度を早める) しつつ、システムの可用性やサイトパフォーマンスを最大化(ユーザ体験品質の向上) することで、結果としてビジネスを成長させるため。

DevOpsにおいて重要な考え方とはなにか？

重要な考え方
- DevOpsという言葉からではなく、そもそもの課題や目指すべき理想の開発体制やサイクルからの逆算で考えること。すなわち、ツールやエンジニアリング戦術ありきで考えないこと。また、Opsに関わる仕事は、(意図せずとも)開発組織内のサイロ化や局所最適な意思決定のガンになりやすい性質があるので、Opsに責任を持つチームのメンバーはシステム面だけに注力するのではなく日々のオンライン・オフラインコミュニケーションの細部まで含め日々自省、自己変革をしていくこと。

ビジネスの成長がゴールであり、そのためにDevはいかに速くフィーチャをリリースするか、Opsはいかにシステムを安定稼働させるかに取り組んでいるとのことです。DevOpsではよく手段が目的化されてしまうと聞きますが、あくまで目的はビジネスの成長であり、そのためには広い視点を持って考え、常に改善に取り組んでいるという点にとても共感しました。

DevとOpsをどのように連携させているのか？

DevとOpsが「ユーザ体験の最大化」という同じ目標へ向かっていること、そして改善を二人三脚で継続的におこなうことが重要と考え、DevとOpsでサービスレベル目標(SLO)を共有しているそうです。

また、SLOの達成度やユーザのサービス利用体感に関わるメトリクスに変化がないかひと目で確認できるレポートを自動生成して社内サーバにホスティングし、Dev(6〜7名)とOps(SREチームの6名)が参加するパフォーマンスモニタリング会を週次で開催して、その中でダッシュボードをチェックしているとのことでした。

チェックした結果、対応すべき事項がある場合はキャパシティ上限に従いDev、Ops(SREチーム)それぞれがタスク（多くても3つ程度）を持ち帰り、翌週までに対応を完了させるような取り組みを継続しているそうです。

正直、開発チーム責任者に最初話をもちかけた時はうまく改善サイクルが回るか分からず、形骸化や負担が増えないかを心配していましたが、結果として非常にうまくいったと考えていて、品質の向上だけでなくサービス品質に対する開発者としてのスタンスというか、文化的な醸成の場としても非常にうまく機能しているとお話しされていました。

まさにこういった継続的な改善活動がDevOpsの文化面で非常に重要だなと思います。

レポートは以下のログをすべてGoogle BigQueryへ集約し、そのデータを元にGoogle Cloud Datalabで作成しているそうです。

Webサーバログ
アプリケーションログ
CloudWatchログ

新メンバーへのキャッチアップの支援をどのようにやっているか？

新メンバーへのキャッチアップ支援は、Terraform、Ansible、Packerのコードを皆で読み合わせる、モブコードリーディング方式で実施しているそうです。もちろんドキュメントも重要ですが、それよりもシステム全体がInfrastructure as codeの実践の結果として自己定義的かつシンプルな状態が維持されていることを重視していて、コードを読むだけでは理解できないような複雑な構成にはそもそもしないという考え方を徹底しているとのことです。

今回インタビューを受けてくれた山本さんも、SREチームにジョインしたタイミングで実践したそうです。

DevOpsを進めていく上で苦労したことなどはなにか？

苦労している点として挙げて頂いたのは以下の二点。

1. ユーザからみた品質低下と、システム上の数値で検知した異常の結びつけ

モニタリング上では異常値を示していたとしても、それがユーザーにとってどういう影響があったのか、他よりも優先して対応する必要があるのか、つまり何をもって異常とするかの定義に苦労していたそうです。

現状はシステムメトリクスがユーザ体験にどのように影響するかをはっきり定義することはできない前提でステークホルダーにも説明していますが、今後はユーザーサイド(端末)でのメトリクスも取得することで、数字で説明していけるような構成を目指しているとのことです。

2. SLO達成のための工数と、事業施策の実現のための優先度判断

「xxというユーザ価値を実現したい」という事業部としての要望と、「yyというエラーを直してユーザ体験を向上させたい」というSLO達成観点でのタスクの優先度判断が日々発生するので、これらをどう折り合いつけていくのかに悩んだそうです。当初はパフォーマンスモニタリング会の場にCTOなど意思決定ができる人を呼んでいたそうですが、今では社内での共通認識の合意形成が進み、SREチームに権限委譲されているそうです。

また、事業レベルでもチームレベルでも優先順位が一意なBacklogで開発項目を管理しており、なぜこのような優先順位になるのかの根拠を前出のダッシュボードを使って説明することで説明責任を果たしているそうです。

プラクティスとツール

CI、デプロイ、構成管理どのようにやっているのか？

CI
- CircleCI
デプロイ
- AWS CodeBuild / CodeDeploy / Auto Scaling
構成管理
- Terraform x Ansible x PackerによるゴールデンAMIモデル

注目すべきは、これらツールの中心にあるSlackのChatopsの存在です。開発者はChatops経由でコミットのDiffを見たり任意の環境へ任意のバージョンのコードをデプロイ、ロールバックすることが可能になっているそうです。デプロイだけでなく、Auto Scaling Groupの調整やインスタンスの検索、ジョブキューの確認からログの閲覧まで、すべてChatopsで実現しているそうです。

もともと恩田さんの入社時は、デプロイでCapistranoを使っている程度で、インフラのコード化は全く実現されていなかったそうです。そこからコツコツとコード化を進め、チームビルディングも行なって今の構成に至ったとのこと。これらの取り組み以外にも、開発環境やリリース前検証環境、カナリアリリースの整備、開発者が安全かつ迅速なリリースをサポートする仕組みを整備したり、次はカオスエンジニアリングに取り組もうとしているなど、日々進化の止まらない攻めの姿勢が本当に素晴らしいと思いました。

障害をどのように検知して、どのような対応フローで進めているのか？

ツール
- Stackdriver Logging
- Datadog
どうやって検知しているか
- DatadogからSlackの専用チャネルへ通知
対応フロー
- 基本気づいた人が対応。ほぼほぼオンコール対応はSREチーム。
- 障害発生したら専用JIRAチケットを作成、自動でSlackチャネルが作成されるので以後そのチャネルでコミュニケーションをとる
- 一次対応終了後、恒久対応の立案および対応完了をもってチケットクローズする
- 大規模障害かつ長時間続く場合はカスタマーケアチームと連携し、ユーザ案内はじめコミュニケーションを開始
考え方
- アラートは対応可能なものでなくてはならない
  - 検知できても打つ手なしでは意味なし
- アラートを鳴らしすぎるのはある意味鳴らないより危険
  - アラート = 即対応が必要なもののみと定義し、監視を設計 & 維持する。でないと形骸化する
  - 狼アラートが多いと、アラートを異常とみなす文化自体が損なわれるので中長期的に危ない

この中で印象に残ったのが、障害時に自動でSlackチャネルが作成される仕組みと、"検知できても打つ手なしでは意味なし"という考え方です。

前者は、一般的に共通チャネル上でやり取りされることが多いと思いますが、経験上会話が入り乱れて混乱することもあったので、専用チャネルが自動で作成されるのはとても良いと感じました。また、後者については、例としてAPIサーバのLA(ロードアベレージ)を挙げてもらったのですが、確かにLAがしきい値を超えたからと言って見てるだけしかできないなら通知する意味がない、それならばAuto Scalingする構成にしておいて特に通知はしない方が結果的には良いという考えです。

また、恩田さんが特に強調されていたのが、MTTR(平均修復時間)の最小化を特に重視している点でした。結局のところ、あらゆる障害を未然に防ぐことは不可能という前提において、障害の発生をいかに早く検知し、激速で戻せる(ロールバックできる)ようにしておくことでSLOを達成するというアプローチは非常に理にかなっていると思います。

私自身、今まではデプロイ、リリース前にいかに障害を防ぐかという視点で、手動の確認などに多くの時間を費やしてきてしまっていましたが、そのような辛いアプローチをとっても必ず障害は発生してしまうので、それならば障害は発生する前提に立って手段を講じるべきでしょう。

環境としてはプロダクション環境と全く同じ構成のステージング環境を構築しているとのことで、プロダクションだけで発生するような障害を無くすとともに、プロダクション環境で障害が発生してロールバックした場合でもステージングで再現できるようにしているとのことです。コスト面を考えると、ついステージングにそこまでコストをかけられなかったりしますが、必要なところにはしっかりとコストをかけているところも素晴らしいと思いました。

最後に

目指すところはどこか？

DevOpsで成功している状況のイメージ
1. 開発者の生産性が最大化(指標：リリース回数) されている
2. MTTR(平均修復時間)の最小化をもってSLO(サービスレベル目標)が達成されて
3. 1,2の結果として、ビジネスが力強く成長している状態

DevOpsという観点では、上記の状態を維持しながら改善を続けていきたいとお話されていました。

今後チャレンジしたいこと

カオスエンジニアリングの導入

今後目指しているのは自己修復的なシステムで、異常を外部から意図的に注入しても可用性、恒常性を保てるかを常に監視することで安定稼働していることを保証できるようなことに取り組んでいきたいとのことです。今はまだ実現できていないそうですが、国内でも先行しているクックパッド（Chaos Engineering やっていく宣言）やGMOペパボ(Redis の障害を想定した避難訓練を行いました)の事例を参考に検討を進めているそうです。

皆様から今後の抱負！

恩田さん

売上が10倍になっても今と同じ仕組みで対応できることを意識している。事業の成長に対して運用コストも線形で増えてしまっていは意味がない。台数などは増えていっても、運用コストは線形にならないようにしたい。

山本さん

カオスエンジニアリングにチャレンジしていきたい。可能な限り多くの回数を試せるような仕組みを整えたいと考えている。一方でマイクロサービスのアーキテクチャやデータ分析基盤の構築なども行なっていきたい。

坂田さん

現状メトリクスはサーバサイド中心に見ているが、今後はクライアントサイドも含めて一気通貫で見れるような仕組みを整備する必要があると感じている。そこまでできればユーザーの実際の不利益も数値化できるので、ユーザーにより良い価値を提供していけると考えている。

絶賛採用活動中

SREチームでは絶賛採用活動中とのことだったので、最後にどういった方に来てほしいかを聞いてみました。

目的思考の強いエンジニア
手段の目的化はだめだと理解しつつも、手段が目的になってしまうような熱量を持ったような人

SREチームでは守りだけでなく、機械学習によるスパムの自動検知や、データ分析基盤の構築など攻めの施策も積極的に行なっているため、具体的にどういった利益、価値を提供できるかというのをボトムアップで上げていけるようなメンバーだと嬉しいとのことです。もちろん敷居は高いと思いますが、大変やりがいのあるチームだと思いますので、ご興味ある方はぜひご応募してみてください。